perf: skip write mutex for PostgreSQL backend#130
Conversation
PostgreSQL handles concurrent writes natively via MVCC, advisory locks, and FOR UPDATE SKIP LOCKED. The single-process write mutex was only needed for SQLite/libsql (which opens separate connections for transactions, causing SQLITE_BUSY conflicts). Now the mutex is conditionally applied only when backend !== 'postgres', unlocking true concurrent write throughput for PostgreSQL deployments. Closes #123 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Summary
The write mutex that serializes all mutating operations was unconditionally applied to all backends, including PostgreSQL. This defeated PostgreSQL's native concurrent write capabilities (MVCC, advisory locks, FOR UPDATE SKIP LOCKED).
Now the mutex is only applied when
backend !== 'postgres'.Why this is safe
claimNextimplementation already usesFOR UPDATE SKIP LOCKED+pg_advisory_xact_lockfor safe concurrent claiming.Test results
Closes #123
🤖 Generated with Claude Code